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REMARKS 

Claims 1-22 are pending. 

Definition of hierarchy: A structure that has a predetermined ordering from high to low. 

For example, all files and folders on the hard disk are organized in a hierarchy, such as a Win 
Folder organization. 

A Win Folder organization manages a computer and requires a knowledge of how folders 
are organized on the hard disk so that a user can locate the file they want to retrieve. A Windows 
disk folder is a simulated paper file folder, except that it is not fixed in size and is only limited by 
the remaining room on your hard disk. 

The route to every file or program stored in a folder on a hard disk is known as the "path." 
One navigates their hard disk visually with a file manager utility known, for example, as Explorer, 
which shows the folder hierarchy on all the computer's drives in its left Window pane. 

The definition of folder hierarchy is: The organization of folders (directories) on a hard disk, 
which is drive-folder-file. 

As one navigates down layers of folders, they are following the path (address) to a specific 

file. 

The Explorer file manager lets you create, copy, move and delete files and folders. In its left 
window, Explorer displays the hierarchy of folders stored on the hard disk or other storage device. 
When you click on a folder in the left Explorer window, its contents appear in the right window. 
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A. Claim 3 was rejected under 35 U.S.C. §102(b) as being anticipated by Rust et al (US 
6,223,134). The applicant respectfully traverses this rejection for the following reason(s). 

Claim 3 is directed towards a method for commonly controlling device drivers, 
comprising, in part, the step of: 

arranging a device independent access hierarchy between an application hierarchy and a 
device driver hierarchy. 

The Examiner states in the rejection (on page 2) "Rust teaches a method for commonly 
controlling device drivers, comprising the steps of: arranging a device independent access hierarchy 
between an application hierarchy and a device driver hierarchy . And refers us to Fig. 5, (Class 
Drivers 304); and col. 13, lines 19-67. 

What Rust may or may not teach is subject matter to be considered under §103, not §102. 

Under §102, there must be no difference between the claimed invention and the reference 
disclosure, as viewed by a person of ordinary skill in the field of the invention. Scripps clinic & 
Research Foundation v. GenentecK Inc., 927 F.2d 1565, 18 USPQ2d 1001, 18 USPQ2d 1896 (Fed. 
Cir. 1991). 

Note that in order for an anticipation rejection to be proper, the anticipating reference must 
disclose exactly what is claimed. "A claim is anticipated only if each and every element as set forth 
in the claim is found, either expressly or inherently described, in a single prior art reference." 
Verdegaal Bros. v. Union Oil Co. of California, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). "The 
identical invention must be shown in as complete detail as is contained in the ... claim. "Richardson 
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v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). Note here that the Examiner has not 
relied on "inherency," accordingly, each and every element must be expressly described in Rust. 

The underlined portion of the Examiner's statement of rejection above is language not found 
in Rust, and is in fact the same language used in the Applicant's claim. 

A review of Rust finds no use of any of the terms "device independent access," "device 
independent access hierarchy," "application hierarchy" and "device driver hierarchy" used in the 
claim. 

Accordingly, the rejection is not clear. 

Although the Examiner refers us to Fig. 5, (Class Drivers 304); and col. 1 3, lines 1 9-67, we 
cannot determine which of Rust ' s elements correspond to the terms "hierarchy," "device independent 
access," "device independent access hierarchy," "application hierarchy" and "device driver 
hierarchy." 

The Examiner is referred to 37 CFR §1.1 04(c)(2) which directs the Examiner to designate 
the particular part relied on as nearly as practicable, when a reference is complex . The pertinence 
of each reference, if not apparent, must be clearly explained. 

Citing Fig. 5, (Class Drivers 304); and col. 13, lines 1 9-67 is clearly not as nearly practicable 
enough since the term "hierarchy" is not used in Rust, and since the term ""device independent 
access" is not used in Rust. 

Accordingly, the rejection of claim 3 is deemed to be in error and should be withdrawn. 



PATENT 
P56833 

Claim 3 is directed towards a method for commonly controlling device drivers, 
comprising, in part, the step of: 

defining functions available in a corresponding device driver amongfunctions of a function 
block in a function table. 

According to the present specification, paragraph [0034] : "In the embodiment of the present 
invention, only functions available in a corresponding device driver among functions of a function 
block defined and standardized in international organizations such as ITU/RFC (International 
Telecommunications Union/Request For Comments), etc. is defined in a function table. The present 
invention employs all function blocks defined in standardized documents made by international 
organizations for standardization such as ITU (International Telecommunications Union), IETE 
(Internet Engineering Task Force), ETSI (European Telecommunications Standardization Institute), 
ATM (Asynchronous Transfer Mode) forum, ADSL (Asymmetrical Digital Subscriber Line) forum, 
etc. In the embodiment of the present invention, only functions available in the corresponding device 
driver among functions of all function blocks defined by the international organizations for 
standardization are re-defined in the function table." 

The Examiner refers us to Rust's col. 6, lines 34-51, IVI engine 306, col. 16, lines 28-49, 
"...array of function names...", and col. 23, lines 29-42. 

Rust's IVI (interchangeable virtual instrument) engine 306 communicates with each of the 
class drivers 304, the generic capabilities portion of the specific driver 308 and the 
instrument-specific capabilities portion of the specific driver 308. The IVI engine also couples to the 
initialization file referred to as IVI.INI 3 1 0. As shown, the IVI engine 306 and the specific driver 308 
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include bidirectional communication. The IVI engine 306 operates to create and manipulate IVI 
instrument driver objects. The IVI engine 306 also manages function pointers to the specific driver 
and calls driver-specific attribute callbacks. The IVI engine 306 further manages all instrument driver 
attributes and performs Set and Get attribute operations. The IVI engine 306 also performs state 
caching and attribute simulation operations. 

When the user application 302 makes a call or invokes a method on the class driver 304, the 
class driver 304 accesses information in the IVI Engine 306. The class driver 304 uses services 
provided by the IVI engine 306 to access the respective function in the specific instrument driver 308 
which performs the operation on the specific instrument. More specifically, when the class driver 
receives a function call, the IVI engine 306 provides a pointer to the class driver, wherein the pointer 
points to the respective function in the specific driver. In other words, all calls to the class driver 304 
actually invoke the specific instrument driver 308 of the instrument being called. Thus the class 
driver 304 itself does not actually configure or "touch" the instrument, but rather preferably in every 
case the specific instrument driver 308 of the instrument is invoked to actually perform the 
configuration or operation. The IVI engine 306 thus operates with a respective class driver 304 to 
enable operation of the class driver 304 within the system. The IVI engine 306 is capable of 
operating with each of the class drivers 304 within the system. Thus the IVI engine 306 is generic 
to each of the class drivers 304 and provides services to each of the class drivers 304. 

The specific driver 308 is operable to use services and/or functions in the IVI engine 306, 
such as set attribute and get attribute functions in the IVI engine 306. Likewise, the IVI engine 306 
is operable to invoke callbacks in the specific driver 308 to perform its services and/or functions. The 
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IVI engine 306 preferably includes a plurality of set attribute and get attribute functions, each for a 
respective data type. For example, the IVI engine 306 preferably includes set attribute and get 
attribute functions for data types such as int32, real 64, Booleans, strings, pointers, etc. 

Therefore, the functions, such as the set and get function, of IVI engine 306 are not functions 
available in a corresponding device driver, but instead are only functions of IVI engine 306. 

Additionally, there is no function table disclosed, and there are no functions of a function 
block in a function table disclosed in Rust, especially with respect to IVI engine 306. 

In the columns cited by the Examiner, Col 23, line36 mentions a table examined by the IVI 
engine 306, and this table is located in IVI.ini (a configuration or initialization file) file 310 of Fig. 
5. 

Rust discloses that the initialization or configuration file (INI file) 3 1 0 comprises information 
on each of the instruments or virtual instruments present in the instrumentation system. The INI file 
310 maps Logical Names used in a program to a Virtual Instrument section. The Virtual Instrument 
Section operates to link a hardware section and a driver section. The Virtual Instrument Section also 
sets driver modes, such as range checking, simulation, spying, interchangeability checking, and 
instrument status checking, using parameters called rangeCheck, simulate, spy, interchangeCheck, 
and querylnstrStatus. The INI file also defines Virtual Channel Names which map channel name 
aliases to instrument-specific channel names and specifies a default instrument setup for the virtual 
instrument. 

For example, if the user application genericaliy references a DMM (digital multimeter) as 
"DMMl the configuration file stores information regarding which actual instrument and instrument 
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driver in the system corresponds to DMM1 . The configuration file stores information regarding the 
address of the instrument and the location of the instrument driver. This enables the system to load 
the specific driver and communicate with the instrument. 

As an example of the initialization operation, the user application calls the init function in 
step 422 with the logical name "DMMl ". The class driver 304 receives the logical name in step 424 
and directs the IVI engine 306 to open up DMMl in step 426. The class driver 304 also provides an 
array of function names in step 426 that it expects the instrument driver 308 to have. The IVI engine 
306 examines the table in the IVI.ini file in step 428, determines the location of DMMl, and loads 
the instrument driver for DMMl in step 430. 

The table in the IVI.ini file 310 is not disclosed as being a function table, and there is no 
mention of functions of a function block in a Junction table anywhere in Rust. 

Accordingly, the rejection of claim 3 is deemed to be in error and should be withdrawn. 

Claim 3 is directed towards a method for commonly controlling device drivers, 
comprising, in part, the step of: 

when a device is initialized, allowing said device independent access hierarchy to generate 
a device handler identifier based on a standardized data format for said device and transmit the 
generated device handler identifier to the application hierarchy of a higher order. 

Here the Examiner refers to several instances wherein the term "handle" appears in Rust, such 
as col. 20, lines 35-46; col 23, lines 12-21; and col. 24, lines 22-29. 

The foregoing feature of claim 3 requires said device independent access hierarchy to 
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generate a device handler identifier. In col. 20, lines 35-46, Rust discloses "the user application 
includes calls to a driver initialization function (init) in the class driver 304 which creates or 
instantiates the driver and returns a handle. 11 There is no device independent access hierarchy 
disclosed in Rust, and it is the class driver 304 which returns a handle. 

The cited section col 23, lines 1 2-21 discusses step 426 in Rust and state: "After step 462 the 
initialization function call originally made by the user application has been completely executed. 
From this point on, whenever the user application 302 calls a function in the class driver, the 
function call includes the handle that is returned from the init function (as discussed above with 
respect to col. 20, lines 35-46) to specify which instrument is being communicated with." See step 
462 in Fig. 7D. 

The cited section col. 24, lines 22-29 of Rust summarizes the forgoing. 

Additionally, of the above mentioned cited sections of Rust, there is no disclosed device 
handler identifier generated in Rust based on a standardized data format. As can be seen from the 
Examiner's rejection, the Examiner appears to only be interested in Rust's disclosure of a handle, 
as there is no mention in the rejection of where Rust is supposed to disclose generation of a device 
handler identifier based on a standardized data format. 

Accordingly, the rejection of claim 3 is deemed to be in error and should be withdrawn. 

Claim 3 is directed towards a method for commonly controlling device drivers, 
comprising, in part, the step of: 

allowing the higher-order application hierarchy to call a predetermined device using the 
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device handler identifier, and allowing said device independent access hierarchy to identify a 
function of the corresponding device driver from the function table using the device handler 
identifier and call the function of the corresponding device driver. 

As noted previously, there is no disclosed device independent access hierarchy and there is 
no disclosed function table in Rust. 

Accordingly, the rejection of claim 3 is deemed to be in error and should be withdrawn. 

B. Claims 1, 2 and 12-21 were rejected under 35 U.S.C. §103(a), as rendered obvious and 
unpatentable, over Rust et al. in view of Pike et al. (US 6,993,772). The Applicant respectfully 
traverses this rejection for the following reason(s). 

Claim 1 

Claim 1 is directed towards a method for commonly controlling device drivers, 
comprising, in part, a step of: 

arranging a device independent access hierarchy between an application hierarchy and a 
device driver hierarchy and applying a standardized rule of said device independent access 
hierarchy to said application hierarchy and said device driver hierarchy. 

As discussed above, Rust fails to discuss a device independent access hierarchy and looking 
to Fig. 5 in Rust, there is no element such as a device independent access hierarchy disposed 
between user application 302 and class driver 304. 

Additionally, Rust fails to discuss an application hierarchy, a device driver hierarchy and 
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a standardized rule. 

Accordingly, the rejection of claim 1 is deemed to be in error and should be withdrawn. 

Claim 1 is directed towards a method for commonly controlling device drivers, 
comprising, in part, a step of: 

allowing said application hierarchy and said device driver hierarchy to access the device 
driver hierarchy and said application hierarchy through the standardized rule of said device 
independent access hierarchy, respectively. 

The Examiner notes that Rust fails to teach the foregoing feature and refers to Pike's 
Instrument Engine 102 and Col. 8, lines 3-14. The Examiner then states it would have been obvious 
to one of ordinary skill the art at the time of the invention was made to combine the teaching of Pike 
and Rust because the teaching of Pike "would improve the system of Rust by allowing 
communication between a user application and device driver such that a response could be returned 
to the user application." 

The Examiner has not identified what such a "response" would be nor why it would be of use 
to Rust. 

The Examiner has not identified any problem with Rust's system and method for controlling 
an instrumentation system such that one of ordinary skill the art at the time of the invention was 
made would have desired to look to the related art for a solution to such a system. 

The Examiner has not identified how a "response" (noting that we have no idea what the 
response is supposed be) would improve the system of Rust by allowing communication between 
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a user application and device driver such that a response could be returned to the user application, 
since communication between a user application and device driver is already allowed such that a 
handle is already returned from class drivers 304 to user application 302 as disclosed in Rust's col. 
20, lines 38-41. 

Thus, without a factual basis to support the basis of obviousness, it appears that the Examiner 
merely speculates that the combination of Pike and Rust would improve the system of Rust. 

Deficiencies in the factual basis cannot be supplied by resorting to speculation or 
unsupported generalities. In re Warner, 379 F.2d 1011, 154 USPQ 173 (CCPA 1967) and In re 
Freed, 425 F.2d 785, 165 USPQ 570 (CCPA 1970). 

Accordingly, the Examiner fails to establish a prima facie bases of obviousness. 

In re Rijckaert, 28 USPQ2d 1955 (CAFC 1993) states: 

"A prima facie case of obviousness is established when the teachings 
from the prior art itself would appear to have suggested the claimed 
subject matter to a person of ordinary skill in the art." In re Bell, 991 
F.2d 781, 782, 26 USPQ2d 1529, 1531 (Fed. Cir. 1993) (quoting In 
re Rhinehart, 531 F.2d 1048, 1051, 189 USPQ 143, 147 (CCPA 
1976). If the examiner fails to establish a prima facie case, the 
rejection is improper and will be overturned. In re Fine, 837 F.2d 
1071, 1074, 5 USPQ2d 1596, 1598 (Fed. Cir. 1988). 

Additionally, Pike fails to teach or discuss the features of claim 1 noted above as lacking in 
Rust, such as, an application hierarchy, a device driver hierarchy and a standardized rule. 

Accordingly, the rejection of claim 1 is deemed to be in error and should be withdrawn. 
Claim 2 is deemed to be non-obvious for the same reasons as discussed above. 
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Claim 12 

Claim 12 is directed towards a method, comprising, in part, a step of: 
requesting loss of signal state information based on a standardized common format by an 

application to a device independent access hierarchy. 

Looking to both Rust and Pike we find no mention of concern with respect to loss of signal 

state information. 

The Examiner refers to Rust's teaching of "check instrument status". However, "check 
instrument status" is deemed not to correspond to loss of signal state information. 

Additionally, it is required that the application make the request to the device independent 
access hierarchy. See Applicant's paragraph [0032]. 

In Rust the "check instrument status" resides in the specific driver 308. 

Accordingly, the rejection of claim 12 is deemed to be in error and should be withdrawn. 

• Claim 12 is directed towards a method, comprising, in part, a step of: 

converting the request from said application into a first device local format and requesting 

a first device driver to provide the loss of signal state information to said device independent access 

hierarchy. 

Here the Examiner refers to Rust's col. 15, lines 24-45, and specifically to lines 26-29, i.e., 
"In other words, when creating a user application 302, the user is generally only required to have 
knowledge of the class driver 304 . . ." 

It is not clear why the Examiner refers to the above cited section of Rust, as there is nothing 
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in col. 15, lines 24-45 dealing with the previous cited portion of Rust regarding "check instrument 
status". 

Similarly, the Examiner refers to Rust's Fig. 8A and col. 24, lines 43-45 which have no 
connection to Rust regarding "check instrument status". 

It appears the Examiner is merely picking and choosing certain parts of Rust in an attempt 
to deprecate the claims. 

It is impermissible within the framework of section 103 to pick and choose from any one 
reference only so much of it as will support a given position to the exclusion of other parts necessary 
to the full appreciation of what such reference fairly suggests to one skilled in the art. 
In re Wesslau, 353 F.2d 238, 241, 147 USPQ 391, 393 (CCPA 1965); see also In re Mercer, 515 
F.2d 1161, 1165-66, 185 USPQ 774, 778 (CCPA 1975). 

One cannot use hindsight reconstruction to pick and choose among isolated disclosures in 
the prior art to deprecate the claimed invention. In re Fine, 837 F.2d at 1075, 5 USPQ2d at 1600. 

Pike was not relied on with respect to the foregoing features of claim 12. 

Accordingly, the rejection of claim 12 is deemed to be in error and should be withdrawn. 
The remaining features of claim 12 and claims 13-21 will not be addressed herein, as it should be 
quite clear that the combined teachings of Rust and Pike do not support the rejection. 
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C. Claim 22 was rejected under 35 U.S.C §103(a), as rendered obvious and unpatentable, 
over Rust et al. in view of Pike et al. and in further view of Kathail et aL (US 6,802,365). The 
Applicant respectfully traverses this rejection for the following reason(s). 

Claim 22 is deemed to be non-obvious for the same reasons as claim 12. Kathail fails to teach 
those features of claim 12 noted as lacking in Rust, or the combination of rust and Pike. 

Claim 22 also calls for varying the addresses of the pointers under the control of said device 
independent access hierarchy when said first device driver is changed to said second device driver. 

Here the Examiner refers to Kathail's discussion of "VerifyFragmentAsDrive" and col. 3 1 , 
lines 50-67, in which there is no teaching of addresses of the pointers, nor varying such addresses. 
Also, there is no teaching that such varying (not verifying as discussed in Kathail) is under the 
control of said device independent access hierarchy, and the "VerifyFragmentAsDrive" discussed 
in Kathail's col. 31, lines 50-67 is not based on when said first device driver is changed to said 
second device driver as claimed. 

Accordingly, the rejection of claim 22 is deemed to be in error and should be withdrawn. 
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D. Claims 4-11 were rejected under 35 U.S.C. §103(a), as rendered obvious and 
unpatentable, over Rust et al. in view of "Applicant's Admitted Prior Art" (AAPA pages 11- 
17). The Applicant respectfully traverses this rejection for the following reason(s). 

It is not clear how the Examiner come to deem the Applicant's disclosure on pages 1 1-1 7 to 
be "Admitted Prior Art", as there is no such admission. 

The Examiner should precisely point out where each feature of claims 4-1 1 are admitted to 
as being prior art. 

For example, it should be pointed out where the feature of said device handler identifier 
being represented as DCB handlerld[xl.x2.x3], where xl, x2 orx3 is an unsigned integer, xl being 
a value of the level 1 meaning a device ID, x2 being a value of the level 2 meaning a logical or 
physical group number of a corresponding device, x3 being a value of a channel meaning a channel 
number of a corresponding device or group, as set forth in claim 4 is admitted prior art (printed in 
a publication or patent in this or a foreign country, or known by others in this country). 

Here the Examiner refers us to page 1 7, lines 8-10 of the present specification, which state: 

"However, in a conventional case, a common structure including a 
base address at the time of initializing a value of the level 1 , a group 
ID corresponding to the level 2 and a channel ID at the time of 
initializing a channel is used." 

As can clearly be seen, page 1 7, lines 8- 1 0 to not include disclosure of the foregoing feature 

of claim 4. 

Accordingly, the rejection of claims 4-1 1 is deemed to be in error and should be withdrawn. 
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The examiner is respectfully requested to reconsider the application, withdraw the objections 
and/or rejections and pass the application to issue in view of the above amendments and/or remarks. 



Should a Petition for extension of time be required with the filing of this Response, the 
Commissioner is kindly requested to treat this paragraph as such a request and is authorized to 
charge Deposit Account No. 02-4943 of Applicant's undersigned attorney in the amount of the 
incurred fee if, and only if, a petition for extension of time be required and a check of the requisite 
amount is not enclosed. 



Respectfully/Submitted, 




Robert E. Bust 
Attorney for Applicant 
Reg. No.: 27,774 



1522 K Street, N.W. 
Washington, D.C. 20005 
(202) 408-9040 

Folio: P56833 
Date: 2/2/07 
I.D.: REB/MDP 
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